AD-A078  124  MASSACHUSETTS  INST  OF  TECH  CAMBRIDGE  ARTIFICIAL  INTE— ETC  F/G  9/2 

COMPUTER  AIDED  EVOLUTIONARY  DESIGN  FOR  DIGITAL  INTEGRATED  SYSTE— ETC(U) 
MAY  79  G  J  SUSSMAN  *  J  HOLLOWAY  »  T  F  KNIGHT  N00014-75-C-0643 
UNCLASSIFIED  AI-M-526  NL 


I  »  I 

*So78lJ4 


ADA078124 


>-1 

O 

CJ> 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  of  THIS  PAGE  fp»l»n 


LEVEL 


REPORT  DOCUMENTATION  PAGE 


1  REPORT  NUMBER 

AIM  526 


/'/, 


(Lfifiy.I_ACCEMlQN  wo. 

/)J-  r>\  6  3 


■4.  TITLE  (And  SutMU»> 

/  Computer  Aided  Evolutionary  Design  for  Digital 


Integrated  Systems 


7.  AUTMORf*^ 

!  Gerald 


-  ) 


IP 


1 


^  Sussman,  Jack ^Holloway ,  Thoma  S7Kgjg;ht  / 


9.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

Artificial  Intelligence  Laboratory 
545  Technology  Square 
Cambridge,  Massachusetts  02139 


/ 


II  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Advanced  Research  Projects  Agency 
1400  Wi Ison  Blvd 
Arlington,  Virginia  22209 


H  MONITORING  AGENCY  NAME  A  ADORESSf//  dlltoront  trom  Controlling  Olllco) 

Office  of  Naval  Research 
Information  Systems 
Arlington,  Virginia  22217 


f' )  y 


READ  INSTRUC 
BEFORE  COMPLETING  FORM 


1.  RECIPIENT’S  CATALOG  NUMBER 


X 


S.  I  TYPE  OF  REPORT  ft  PERIOD  COVEREO 

memorandum  x  ■  r 

*  / 


•J  / 


•.  PERFORMING  ORG.  REPORT  NUMBER 


k.  contract  or  grant  number^*; 
10014-7  5-C-0643, 


✓  AF(fSR-78-3593 


10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  *  WORK  UNIT  NUMBERS 


//' 


IZ.  REPORT  DATE 

l  May  1^79  ~ 


I).  HUMBER  OF  PAGES 

24 


is  security  class.  r* i  im*  report, 

UNCLASSIFIED 


IS*,  declassification/  downgrading 
SCHEDULE 


IS  DISTRIBUTION  STATEMENT  (of  Ihlt  Report) 


Distribution  of  this  document  is  unlimited. 


D  D  C 

niECSEDnPE 


17.  DISTRIBUTION  ST  A  TEMENT  (of  f/lo  *S»»r*e»  or>l»rorf  If,  ftloe*  JO,  It  WINororir  I 


DEC  13  »9T9 


l^LbU  U  IS 

D 


18  SUPPLEMENTARY  NOTES 


None 


19.  KEY  WORDS  fConl/nu*  on  r*ror*o  */</•  1/  ntcfmrr  «n4  Idortll/r  *r  Sloe*  m»b«) 


Digital  Integrated  Systems 
Computer  Aided  Evolutionary  Design 
Artificial  Intelligeiy^  JL  ^ 


i  1 


U 


3  4 


20.  ABSTRACT  (Continue  on  rovreo  ride  It  necoooory  mnd  identity  by  block  numbor) 

We  propose  to  develop  a  computer  aided  design  tool  which  can  help  an  engineer 
deal  with  system  evolution  from  the  initial  phases  of  design  right  through 
the  testing  ad  maintenance  phases.  We  imagine  a  design  system  which  can  func¬ 
tion  as  a  junior  assistant.  It  provides  a  total  conversational  and  graphical 
environment.  It  remembers  reasons  for  design  choices  and  can  retrieve  an d  do 
simple  deductions  with  them.  Such  a  system  can  provide  a  designer  with  in¬ 
formation  relevant  to  a  proposed  modification  and  can  help  him  understand  the 


DD  1473 


COITION  OF  I  NOV  89  IS  OBSOLETE 
S/N  OI0J-0M-880I  I 


UNCLASSIFIED 

SE CURlTV  CLASSIFICATION  OF  THIS  PAGE  fWW**  Doro 


\\ 


20.  consequences  of  simple  modifications  by  pointing  out  the  structures  and  functions 

which  will  bo  affected  by  the  modifications.  The  designer's  assistant  will  maintain 
a  vast  amount  of  such  annotation  on  the  structure  and  function  of  the  system  being 
evolved  and  will  be  able  to  retrieve  the  appropriate  annotation  and  remind  the 
designer  about  the  features  which  he  installed  too  long  ago  to  remember,  or  which 
were  installed  by  other  designers  who  work  with  him.  We  will  develop  the  fundamental 
principles  behind  such  a  designer's  assistant  and  we  will  construct  a  prototype 
system  which  meets  many  of  these  desiderata. 


Ascesslobltr 


mis  GHU1 
DOC  TAB 
Ubnxnounced 
Just  if  loot  ler. 


* 


By 

Dlatrl 

Avnil 

but  ion/ 

ability  Codes 

Dlst 

Avail n 
spec 

nd/or 

ul 

MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 
ARTIFICIAL  INTELLIGENCE  LABORATORY 


A1  Memo  No  52(» 


May  1979 


Computer  Aided  Evolutionary  Design  for  Digital  Integrated  Systems 

by 

Gerald  Jay  Sussman,  Jack  Holloway,  and  Thomas  F.  Knight,  Jr. 


Abstrai  t 

We  propose  to  develop  .1  computer  aided  design  tool  which  can  help  an 
engineer  ileal  with  system  evolution  from  the  initial  phases  of  design  right 
through  the  testing  and  maintenance  phases  We  imagine  a  design  system  which 
can  function  as  a  junior  assistant  It  provides  a  total  conversational  and 
graphical  environment.  It  remembers  the  reasons  for  design  choices  and  can 
retrieve  and  do  simple  deductions  with  them.  Such  a  system  can  provide  a 
designer  with  information  relevant  to  a  proposed  modification  and  can  help  him 
Understand  the  consequences  of  simple  modifications  by  pointing  out  the 
structures  and  functions  which  will  be  affected  In  the  modifications.  The 
designer’s  assistant  will  maintain  a  vast  amount  of  such  annotation  on  the 
structure  and  function  of  the  system  being  evolved  and  will  be  able  to  retrieve 
the  appropriate  annotation  and  remind  the  designer  about  the  features  which  he 
installed  too  long  ago  to  remember,  or  which  were  installed  by  other  designers 
who  work  with  linn  We  will  develop  the  fundamental  principles  behind  such  a 
designer’s  assistant  and  we  will  construct  a  prototype  system  which  meets  many 
of  these  desiderata 
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The  Problem 

I  he  integrated  circuit  revolution  It. is  leil  to  .1  i.ist  increase  in  the 
complexity  of  the  electrical  aitifacts  which  can  he  constructed  monolit hically .  In 
the  design  of  hardware  systems,  we  are  rapidly  approaching  the  complexity 
barrier  which  has  for  long  been  apparent  in  the  design  of  software  systems.  1  he 
turn-around  time  for  realization  of  a  new  design,  from  conception,  through 
synthesis  and  debugging  has  become  excessive,  hence  we  aie  not  developing  new 
designs  at  a  reasonable  rate  I  his  is  not  particularly  a  problem  of  integrated 
circuits,  or  of  programming  systems,  but  rather  a  fundamental  problem  which  can 
best  bo  viewed  in  a  larger  context  There  are  inherent  limitations  to  the 
complexity  that  the  unaided  designer  can  control  in  any  engineering  situation  - 
from  a  complex  electrical  system  to  a  space  vehicle  or  a  nuclear  |xrwer  plant. 
The  thrust  of  our  proposal  must  he  viewed  as  attacking  t lie  problems  associated 
with  integrated  systems  from  this  larger  context  1  / 

The  evolutionary  nature  of  large  engineered  systems  is  a  crucial  feature  of 
their  complexity  I  he  specifications  change,  the  design  changes,  and  as  bugs  are 
discovered,  the  implementation  changes  to  correct  them  1  he  changes  are 

required  because  it  is  not  possible  for  the  designers,  or  the  potential  users  of  a 

system,  to  foresee  all  of  the  opportunities  for  using  the  system  Also,  the 

environment  in  which  the  system  will  operate  is  itself  subject  to  change.  Besides 
this  external  reason  for  the  evolutionary  nature  of  large  systems,  there  is  also  an 
internal  reason  If  all  of  the  relevant  constraints  were  considered  at  once  in 
order  to  arrive  at  a  perfect  solution  in  the  first  place,  the  details  would 

overwhelm  the  designer's  cognitive  abilities.  A  more  effective  strategy  is  to  start 
with  a  solution  which  is  reasonably  close  to  correct  and  modify  it  repeatedly 
until  an  acceptable  solution  is  reached  • 

What  is  needed  is  a  computer  aided  design  tool  which  can  help  an 

engineer  deal  with  system  evolution  from  the  initial  phases  of  design  right 

through  the  testing  and  maintenance  phases.  We  imagine  a  design  system  which 

can  function  as  .1  junior  assistant  It  provides  a  total  conversational  and 

graphical  environment  It  remembers  the  teasons  foi  design  choices  and  can 

retrieve  and  do  simple  deductions  with  them  Such  a  system  can  provide  a 
designer  with  information  relevant  to  a  proposed  modification  and  can  help  him 
understand  the  consequences  of  simple  modifications  by  pointing  out  the 

structures  and  functions  which  will  be  affected  by  the  modifications  I  he 

designer's  assistant  will  maintain  .1  vast  amount  of  such  annotation  on  the 

structure  and  function  of  the  system  being  evolved  and  will  be  able  to  retrieve 
the  appropriate  annotation  and  remind  the  designer  about  the  features  which  he 
installed  too  long  ago  to  remember,  or  which  were  installed  by  othet  designers 
who  wvik  with  I11111  We  will  develop  the  fundamental  principles  behind  such  a 
designer's  assistant  and  we  will  construct  a  prototype  system  which  meets  many 
of  those  ilcsuler.it. 1 
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Engineering  Problem  Solving 

One  necessary  subgoal  of  our  integrated  system  research  program  is  to 
further  develop  om  theory  of  how  skilled  people  (such  as  engineers  and 
technicians)  uinleistand  deliberately  constructed  technological  artifacts  In  most 
engineering  disciplines  theie  is  already  an  extensive  theory  ol  how  the  physical 
principles  which  underlie  the  operation  of  the  aitilacts  are  applied  in  any 
particular  design  In  fact  most  of  the  formal  knowledge  taught  m  engineering 
classes  is  a  (mathematic.il)  tlieoiy  of  how  the  artifacts  work  --  how  their 
behavior  may  he  derived  fiom  fundamental  physical  principles  But  an  engineer 
knows  much  moic  than  |ust  the  physical  principles  and  their  consequences  He 
has  a  great  deal  ol  "tacit  knowledge"  which  allows  him  to  apply  his  physical 
knowledge  efficiently  to  solve  problems  of  design,  synthesis  and  analysis.  This 
tacit  knowledge  is  not  taught  explicitly  in  engineering  classes  nor  is  it  written  in 
engineering  texts  It  is  usually  considered  informal  and  untcachahlc,  except  by 
actual  experience 

lheie  is  almost  no  formalized  theory  of  how  the  engineer  himself  operates 
-•  how  he  must  ptoceed  in  evolving  a  design  when  given  a  set  of  requirements  or 
even  how  he  must  proceed  m  understanding  an  existing  design.  I  here  is  a 
"competence  theory"  of  the  engineered  structures,  but  there  is  no  "performance 
theory"  ol  the  enguieeiing  process’.  1  his  is  not  surprising  I  he  performance 
theory  is  fundamentally  imperative,  but  before  people  began  to  study  algorithms 
as  a  subject  there  were  no  formal  languages  in  which  it  was  convenient  to 
express  such  a  thcoiy  In  fact,  before  this  time  it  was  not  even  realized  that 
siu  h  languages  were  necessary  l  he  advent  of  programmable  computing 
machines  placed  great  emphasis  on  the  development  of  convenient  and  expressive 
formalisms  foi  desettbmg  procedures  We  have  developed  performance  theories 
for  some  aspects  ol  engineering  Such  a  theory  is  a  set  of  rules  which  guide  the 
behavior  of  engmeeis  We  test  our  theories  by  implementing  computer  programs 
based  on  these  rules  which  model  the  behavior  of  engineers  Successful  theories 
are  directly  of  practical  value  because  they  automate  newly  understood  parts  of 
the  engineering  process  and  can  thus  be  turned  into  engineering  tools 

The  development  of  a  theory  of  engineering  performance  knowledge  is  of 
considerable  significance 

I  Understanding  this  currently  tacit  knowledge  will  result  in 
the  consti  uction  of  powerful  computer-aided  systems  for 
automating  the  routine  aspects  of  design,  construction,  testing, 
and  maintenance  of  complex  systems  Such  aids  cease  being 
luxunes  and  quickly  become  essential  as  the  complexity  of 
systems  increases  We  are  already  beginning  to  hit  the 
complexity  barrier  in  the  long  turn  around  time  for  design  of 
intcgiated  circuits.  We  have  long  been  on  the  wrong  side  of 
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this  barrier  m  t he  design  of  large  software  systems. 

2  Making  the  tacit  knowledge  of  engineers  more  explicit  will 
result  m  the  development  of  more  effective  design 
methodologies.  We  are  now  in  the  descriptive  phase  of 
development  of  our  theories  Predictive  tesults  will  improve 
both  computer-driven  and  human  performance  in  developing 
complex  systems 

}  Making  the  tacit  knowledge  of  engineers  more  explicit  will 
improve  our  ability  to  describe,  explain,  and  teach  the  process 
of  engineering 

4  Engineering  design  is  an  almost  ideal  domain  in  which  to 
learn  about  how  experts  reason,  and  how  students  learn  to  be 
experts  Much  of  the  actual  competence  knowledge  is  already 
formalized.  Answers  produced  by  a  performance  theory  are 
thus  testable  Much  of  the  structure  of,  and  the  motivation  for 
the  performance  theory  is  already  in  place  as  engineers  have  an 
extensive  vocabulary  of  informal  descriptions  of  what  they  are 
doing 

5  Results  obtained  in  the  study  of  design  methodology  for 
digital  integrated  systems  may  be  applicable  in  other  problem 
domains 


Why  We  Need  A  Sophisticated  Theory  of  Design 

The  basic  strategy  of  coping  with  a  complex  problem  is  to  find  or  impose 
structure  on  the  problem  which  allows  breaking  it  up  into  manageable  pieces. 
Each  piece  can  then  be  worked  on  separately.  This  must  be  done  so  that  a 
solution  to  the  whole  can  be  composed  from  the  solution  to  the  parts  of  the 
problem  Often  a  system  can  be  partitioned  into  pieces  which  are  more  or  less 
disjoint  and  which  together  cover  the  entire  system  The  total  system  can  be 
understood  by  combining  our  understanding  of  the  pieces  and  our  understanding 
of  the  composition  by  which  the  pieces  constitute  the  system.  Similarly,  each 
piece  may  be  further  partitioned.  In  this  way  we  derive  a  single  tree-like 
decomposition  of  the  system  *-  a  hierarchy. 

This  observation  has  resulted  in  a  plethora  of  shallow  methodologies 
which  are  collectively  called  "structured  design"  4  In  structured  design  the  system 
under  development  is  conceptualized  as  a  single  hierarchy  where  the  system  is 
recursively  broken  into  parts,  each  of  which  represents  a  particular  segment  of  its 
ultimate  structure  These  theories  provide  considerable  power  in  organizing  the 
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thoughts  ot  designets  .nnl  in  structuring  computer-aided  design  systems,  but  they 
must  ultimately  break  down  in  sufl iciently  complex  re.il  designs 

I  he  problem  is  th.it,  m  sufficiently  complex  sxsiems,  .it  any  stage  there  is 
usually  more  than  one  way  of  usefully  partitioning  a  segment  If  this  is  so,  then 
a  single  hierarchs  does  not  suffice  to  indicate  all  of  the  conceptual  pieces  of 
interest  m  the  system  Pieces  whose  sub-pieces  are  localized  by  one 
decomposition  will  have  those  sub-pieces  widely  dts|H*tsed  throughout  another. 
Additionally,  a  single  sub  piece  may  play  several  roles  in  each  decomposition  it 
appears  m  ’’ 

I  or  example,  when  designing  a  simple  microprocessor,  one  way  to  proceed 
is  to  think  m  teims  of  a  state-machine  controllei  which  is  used  to  control  a  set 
of  registers  ami  data  paths.  I  he  state  machine  may  be  implemented  as 
Combinational  logic  and  a  state  register  In  some  technologies,  eg,  two-phase 
chxk  dynamic  MOS,  a  register  may  be  expanded  as  a  pair  of  linked,  clocked 
inverters  and  a  |»oition  of  the  combinational  logic  may  be  done  on  each  phase  of 
the  clock  I  It  us,  m  this  technology  there  may  be  no  single  physical  realization  of 
the  state  register  localized  on  the  chip 

Suppose,  further,  that  we  want  the  registers  which  are  controlled  by  our 
state  machine  to  be  bussed  together.  I  he  bus  is  a  real  conceptual  entity  about 
which  the  data  paths  ate  organized  We  must  have  a  description  of  the  register 
array  in  which  the  bus  is  a  localized  concept  so  that  we  can  say  specific  things 
about  it  l  or  example,  we  may  want  to  make  assertions  which  constrain  the 
communications  conventions  However,  in  a  structural  hierarchy  there  is  no 
particular  locale  for  the  bus  because  the  bus  is  structurally  distributed 
throughout  the  register  array. 

Keen  worse,  consider  the  high  level  block  labeled  "instruction  decoding"  in 
a  hierarchical  description  Not  only  is  the  logic  for  this  box  physically 
distributed,  but  it  also  is  implemented  with  techniques  which  overlap  other 
aspects  of  the  decomposition  A  good  example  is  the  selective  gating  of  clock 
signals,  overlapping  a  clock  distnhution  function  with  a  decoding  function.  Other 
decoding  may  be  integrated  as  part  of  other  functional  modules  in  the  system 
The  decoding  of  the  arithmetic  function  field,  foi  instance,  may  be  an  integral 
part  of  the  structure  of  the  arithmetic  logic  unit 

1  hus  one  aspect  of  developing  a  more  poweiful  theory  of  the  design 
process  than  "structured  design"  is  the  development  of  descriptive  mechanisms 
which  capture  the  powei  of  the  decoiti|vosition  strategy  without  the  restrictions 
on  what  can  actually  be  expressed  ini|vsed  by  a  simple  hierarchical  development. 
These  problems  with  stmetured  design  theories  aie  not  in  any  way  restricted  to 
the  world  of  digital  integrated  systems,  engineers  in  any  discipline  need  to 
examine  the  systems  they  ate  designing  from  many  |v*mts  of  view  A  electrical 
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circuit  designer  is  often  interested  in  the  bias  model  of  a  circuit,  the  incremental 
model,  the  low  frequency  model  of  the  incremental  model,  and  the  high 
frequency  model  of  the  incremental  model,  the  noise  model  and  the  power 
distribution  model  Each  of  these  viewpoints  imposes  Hs  own  decomposition  of 
the  system  under  examination,  and  each  provides  structure  and  information  to 
processes  working  from  other  viewpoints. 


Our  Developing  Theory 

\\'e  are  developing  a  performance  theory  of  engineering  design,  that  is,  a 
set  of  rules  which  characterize  the  way  in  which  engineers  behave  when 
confronted  with  a  design  problem.  In  order  to  express  this  theory  we  are 
developing  a  methodology  adequate  to  capture  these  mlcs.  We  call  this  the 
Design  Procedure  System  because  we  will  use  it  to  express  the  procedures  which 
an  engineer  will  go  through  in  the  routine  development  of  a  design.  The  design 
language  has  two  components:  the  design  procedure  language  and  the  design 
plan  language.  The  design  procedure  language  is  a  very  high  level  language  for 
expressing  design  procedures  --  the  sequences  of  actions  a  designer  goes  through 
in  evolving  a  design.  The  design  plan  language  provides  special  data  structures 
for  representing  the  state  of  a  design.  These  are  used  for  representing  the  data 
on  which  the  design  procedures  operate. 

The  design  plan  is  essentially  a  data  structure  which  describes  the  object 
being  designed  at  many  levels  of  detail  and  which  captures  the  various  models 
which  are  applied  to  it  I  he  design  plan  provides  locales  to  hang  information 
such  as  why  a  particular  goal,  say  a  multiplexer,  was  implemented  in  a  particular 
way,  rather  than  using  alternative  approaches.  1  lie  design  plan  contains  active 
data  structures,  called  constraint  boxes,  which  autonomously  check  and  criticize 
certain  aspects  of  the  evolving  design  and  which  compute  some  properties  of  the 
design  as  consequences  of  others  by  a  process  we  call  pi  op.ig.it ion  6 

The  language  of  design  plans  is  crucial  to  the  success  of  this  project.  It 
must  be  rich  enough  to  allow  the  description  of  complex  entities  which  are  not 
entirely  hierarchical  It  must  be  possible  to  capture  the  various  decompositions 
of  a  system  that  a  designer  wants  to  think  about.  An  entity  may  be  described  in 
terms  of  several  alternate  dccoin|x>sitions  into  parts.  In  fact  it  may  have 
different  names  from  different  viewpoints.  Additionally,  we  must  be  able  to 
specify  th.it  a  structure  is  an  instance  of  a  prototype  which  is  an  element  of  a 
previously  defined  class  from  which  it  inherits  structure,  appropriate  procedures, 
and  decompositions,  and  that  classes  mav  be  themselves  subclasses  of  other 
classes.7  We  already  have  considerable  experience  with  the  development  of  a 
language  of  design  plans  in  two  domains  which  arc  related  to  integrated  systems 
-*  electrical  circuits  and  I  ISP  programs  that  manipulate  data  bases. 
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The  design  procedure  language  is  concerned  with  formalizing  the 
particular  tasks  that  must  he  performed  when  attempting  to  develop  a  design 
plan.  These  tasks  are  described  in  terms  of  rules.  'I  he  language  provides  design 
procedure  primitives  and  means  of  combining  simple  design  procedures  to  make 
compound  ones.  It  also  provides  abstraction  mechanisms  which  allow  one  to 
wrap  up  and  generalize  a  particular  design  procedure  developed  in  a  particular 
design  Some  of  the  rules  that  must  be  expressed  are  synthesis  rules  which  tell 
how  particular  goals  may  be  implemented.  Other  ruics  are  for  information 
gathering.  These  perform  analysis  on  partially  instantiated  structures.  Other 
rules  impose  constraints  or  critics  A  critic  watches  for  and  complains  about 
violations  of  rational  form  or  violations  of  constraints  that  must  be  enforced. 
Other  constraints  are  used  to  deduce  some  design  parameters  from  others  by 
propagation  of  constraints. 

Every  deduction  made  by  any  design  procedure  or  constraint  must  be 
annotated  by  the  name  of  the  procedure  which  made  the  deduction  and  the  data 
which  went  into  that  particular  deduction  We  believe  that  it  is  essential  that 
the  design  system  which  we  are  envisioning  be  thoroughly  responsible  for  its 
behavior.  This  is  essential  to  the  debugging  of  the  design  procedures  and  also  it 
is  essential  to  the  control  of  the  deductive  system  so  that  we  can  retract  any 
assumption  and  all  of  its  consequences.  It  is  critical  in  the  context  of 
evolutionary  design.  These  dependencies  are  also  very  useful  to  a  user  who 
wants  to  discover  why  the  system  believes  what  it  docs  about  his  design  — 
especially  if  it  is  reminding  him  of  some  detail  which  he  has  forgotten.  We  have 
had  consider. ible  experience  now  with  dependency-controlled  data  bases. 

The  language  of  design  must  be  powerful  enough  to  capture  such  subtle 
notions  as  a  methodology.  For  example,  the  single  level  polysilicon  NMOS 
process  places  enough  restrictions  on  relationships  between  wire  levels  that  we 
can  quickly  develop  an  idea  of  a  "reasonable"  geometric  methodology.  The 
ground  and  VDD  wires  carry  power,  and  except  perhaps  at  their  deepest 
branches,  are  required,  for  reasonable  voltage  drops,  to  be  run  in  low  resistance 
metal.  The  direction  of  these  ground  and  VDD  lines  defines  a  local  coordinate 
axis.  Other  metal  lines  must  be  routed  parallel  to  the  power  wiring,  to  avoid 
crossing  it.  We  need  a  set  of  wires  which  can  locally  travel  at  right  angles  to  the 
metal  wiring.  Either  polvsilicon  or  diffusion  would  serve  the  purpose.  But,  in 
the  silicon  gate  technology,  transistors  arc  formed  wherever  there  is  polysilicon 
over  diffusion.  If  both  poly  and  diffusion  are  to  be  used  as  wires,  their 
predominant  axes  must  be  parallel,  lest  unwanted  transistors  will  be  formed  at 
their  crossovers. 

Lead  bonding  constrains  locations  of  I/O  pads  to  the  periphery  of  the 
chip.  Long  standing  convention  defines  the  location  of  certain  pads,  such  as 
power,  ground,  and  clocks 
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With  ;i  few  simple  constraints,  we  have  arrived  at  a  very  clear  picture  of 
what  the  major  wire  orientation  of  almost  any  large  NMOS  circuit  is  likely  to 
be.  We  will  develop  a  way  to  express  such  geometric  conventions,  in  the  same 
way  we  describe  a  methodology  for  logic  design.  In  the  NMOS  design  situation, 
the  choice  available  in  this  methodology  is  very  small.  With  multi-level  metal  or 
a  different  process,  the  designer  may  independently  be  able  to  specify  a  process,  a 
geometric  design  methodology,  and  a  logic  design  methodology. 


Our  DcsiRn  System 

Our  computer-aided  design  system  is  to  be  built  around  the  design 
procedure  system  and  an  appropriate  library  of  design  procedures  and  design 
plans  We  expect  that  designers  using  our  svstem  will  develop  additional  plans 
and  procedures  which  will  be  added  to  the  library  and  thus  shared  with  other 
members  of  the  design  community.  A  designer  may  at  any  time  either  generalize 
or  specialize  a  procedure  or  plan  for  his  immediate  use.  Each  element  of  the 
library  will  be  indexed  for  easy  reference,  and  will  be  annotated  by  information 
describing  how  it  was  derived,  by  the  application  of  procedures  to  other  design 
plans  and  procedures. 

The  design  plan/proccdure  languages  form  an  extensible  base  upon  which 
the  designer  builds  a  vocabulary  of  cliches  -  a  new  language  which  he  then  uses 
to  describe  his  system.  This  is  not  just  a  hardware  description  language,  though 
it  is  certainly  powerful  enough  to  describe  hardware  structures.  In  fact  it  is  a 
language  in  which  one  describes  methods  of  design.  The  designer  tunes  the 
methodology  to  meet  the  architecture  being  implemented.  Part  of  the  design 
specification  is  generated  automatically  by  instantiating  customized  abstractions. 
These  fragments  can  be  the  basis  of  a  library  of  commonly  used  functions  and 
procedures. 

One  way  of  providing  flexibility  in  either  layout  or  logical  structure  is  by 
associating  design  procedures  with  generic  design  plan  fragments.  The  design 
languages  allow  one  to  write  custom  design  procedures  that  are  local  to  a 
fragment.  In  this  way  it  is  possible  to  craft  very  general  abstractions.  Simple 
methods  may  in  fact  be  just  the  instantiating  and  interconnecting  previously 
defined  chunks  of  hardware.  One  may  define  more  advanced  methods  such  as 
"the  method  of  running  a  power  wire  through  a  particular  kind  of  register  cell" 
or  "the  method  of  computing  the  pull-up  ratio  for  driving  a  particular  capacitive 
load". 


This  is  preferable  to  having  a  macrocell  library  consisting  of  a  plethora 
of  minor  variations  on  one  theme.  The  design  procedure  language  provides 
expressive  constructs  for  developing  appropriate!)  tailored  instantiations  of  the 
general  concept.  It  has  control  structure,  a  sub-part  naming  mechanism  and  a 
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vocabulary  of  methods  for  sxnthesis  and  modification.  A  design  procedure  may 
either  const! net  an  expansion  or  modify  a  prototype  according  to  the  parameters 
of  the  call  for  example,  the  generic  concept  "multiplexor"  should  suffice  to 
implement  instances  that  vary  in  the  number  of  bits,  control  buffering,  or  select 
decoding  method  I  here  should  also  be  flexibility  in  the  layout  to  accommodate 
different  spacing  in  the  array  of  input  lines. 

I  he  design  plan  language  is  used  to  represent  the  state  of  a  design.  We 
envision  the  designer  as  using  design  procedures  to  manipulate  the  current  design 
plan  He  max  refine  it,  modify  it,  extend  it,  study  it,  analyze  parts  of  it,  and  use 
it  to  help  debug  and  test  hardware  described  by  the  plan.  1  he  design  state  of  a 
functional  block  is  a  mixture  of  the  instantiation  state  of  the  fragment,  associated 
mask  layout,  constraints  relative  to  other  structures,  design  decisions,  annotations, 
and  violations.  Some  parts  of  the  design  may  be  completely  specified,  but  others 
may  only  exist  as  uninstantiated  or  even  unspecified  fragments.  A  group  of 
elements  can  be  represented  by  an  abstraction  that  captures  the  important 
external  shape  and  connections,  or  by  an  abstraction  which  captures  the  essential 
functionality  but  suppresses  the  internal  detail  Deductions  such  as  rough 
estimates  of  propagation  delay  or  chip  area  can  be  made  in  the  face  of 
incomplete  information.  This  allows  the  designei  to  use  a  top-down  approach  to 
a  complex  design  problem  when  this  is  appropriate 

In  order  to  allow  general  design  procedures  there  must  be  a  uniform 
naming  mechanism  In  which  a  conceptual  entity  may  be  referenced  relative  to 
the  some  current  focus  of  attention.  To  this  end  every  conceptual  entity,  be  it  a 
physical  object  or  location,  or  a  functional  object,  has  an  explicit  data  structure 
which  designates  it  I  his  data  structure  may  have  several  names,  but  it  has  at 
least  one  name  by  which  it  may  be  referenced  in  a  uniform  manner  by  any 
design  procedure  1  hus  there  are  no  "hidden  variables"  or  implicit  references  in 
the  system  This  allows  us  to  attach  information  (assertions,  properties, 
constraints)  to  any  object,  facilitating  complete  documentation  of  the  design  plan. 

Any  fact  or  value  known  by  the  system  has  a  justification  which  describes 
why  the  system  believes  it  These  justifications  must  be  either  that  the  fact  was 
tendered  by  a  user  or  that  it  was  derived  by  some  design  procedure  (or 
constraint)  from  other  known  facts,  these  justifications  make  it  possible  for  a 
user  or  design  procedure  to  consider  or  make  incremental  modifications  to  a 
design,  without  disturbing  features  of  the  design  which  are  not  dependent  upon 
the  incremental  modification  They  allow  the  user,  in  an  evolutionary  setting,  to 
consider  con  equences  of  minor  modifications  I  hoy  also  allow  a  user  or  a  design 
procedure  to  determine  what  assumptions  any  fact  depends  upon,  and  how. 

The  system  allows  multiple  alternate  representations  of  the  same  entity, 
and  it  allows  these  representations  to  communicate  In  many  cases  some  of  the 
representations  are  the  results  of  applying  design  procedures  to  other 
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represent. ittons  l  or  example  the  maze  uniter  max  he  applied  to  a  partially 
specified  lax  out  of  a  circuit  segment  to  produce  a  further  specified  layout  of  that 
segment  1  ach  of  those  representations  is,  hoxxexer,  independently  tnanipulable 
by  further  design  procedures  (or  by  the  user  calling  the  design  procedure 
primitives).  So  if  the  engineer  really  doesn’t  want  a  particular  xvire  routed  by 
the  router  to  go  where  it  put  it,  he  can  change  it  in  tin  representation  which  was 
the  output  of  the  router  l  his  will  have  the  ellect  of  updating  the  justifications 
in  the  connections  betxveen  the  two  representations  so  that  the  new 
representation  will  be  thought  of  descending  from  the  old  representation  through 
the  ma/e  router  except  that  the  particular  wire  was  changed. 


An  Kxnmplc  of  Design 

We  noxx  display  an  example  of  the  type  of  behavior  that  xxe  expect  from 
our  pro|vsed  computer  aided  design  system.  While  xxe  arc  not  entirely  sure  of 
the  detailed  implementation  of  the  capabilities  which  xxe  indicate,  we  feel 
confident  that  they  are  feasible 

Consider  the  problem  of  designing  a  parallel  multiplier-accumulator  xvhich 
might  be  a  component  of  a  signal  processing  chip.  I  he  designer  first  produces  a 
rough  data  path  diagram  (see  below)  showing  the  interconnection  of  instances  of 
fragments  such  as  registers,  adders,  anti  multipliers  1  his  captures  one 
decomposition  that  seems  to  be  functionally  appropriate  and  xvhich  perhaps  will 
reflect  the  physical  layout  of  the  device  as  well  However,  certain  information  is 
missing  or  incompletely  specified. 

Some  deductions  can  already  be  made  to  fill  in  some  of  the  missing 
information  For  example,  consider  the  adder  in  the  middle  of  the  block 
diagram.  It  is  shoxvn  to  have  a  3?  bit  input  and  a  32  bit  input.  The  adder 
fragment  type  can  immediately  infer  the  length  of  the  adder  chain  and  thus 
estimate  the  maximum  time  delay,  the  approximate  area  that  the  adder  will  take 
up,  the  poxver  that  xvill  be  needed  to  fuel  the  adder,  etc  1  hese  approximate 
deductions  can  be  made  without  further  examination  of  the  details  of  the  adder 
chain  because  of  default  assumptions  stored  xvith  the  adder  fragment.  Similar 
deductions  can  be  made  about  other  blocks  m  the  block  diagram.  This 
information  can  be  combined  to  gixe  estimates  of  total  delay,  poxver  consumed, 
and  area  needed  --  all  without  further  refinement  In  fact,  xxe  can  simulate  the 
circuit  at  this  level  of  detail  enough  to  determine  that  the  proposed  design 
actually  has  a  chance  of  working. 

Simple  qualitative  analysis  of  the  circuit  at  dm  level  of  detail  can  point 
out  potential  problems  and  situations  which  xvill  have  to  be  attended  to  later. 
For  example,  critics  associated  with  the  adder  fragment  xvill  notice  that  the 
instance  shown  docs  not  have  the  same  number  of  bits  on  both  inputs.  This 


VISI  -  May  fQ/Q 


MIT  Al  i  ab 


1 1 


sioiHtcriONAi  pom 
•  v(N  ISfOUl 
Ml  LOAD  OAIA  IN) 


BlPIRK  TlONAl  POM  IS 
IXTI*  OUT  MSr  OUI.  PRI  l  OAO  DATA  INI 


either  is  an  error  or  will  require  lh;it  the  designer  decide  how  to  rectify  the 
anomaly.  The  system  will  notify  the  designer  of  the  problem  and  add  it  to  the 
queue  of  pending  problems  which  must  be  solved  before  the  device  is  considered 
ready  for  cooking. 

Nest  the  designer  directs  the  system’s  focus  to  a  particular  part  of  the 
design.  Normally  this  is  what  he  thinks  will  be  the  most  constraining  segment. 
For  example,  one  common  design  goal  in  constructing  circuits  is  to  compose 
regular  arrays  of  logic  by  abutting  them  I  Ins  requires  that  a  common  pitch  be 
found.  I  he  designci  is  now  going  to  try  to  think  about  his  stiucturc  in  terms  of 
the  pitch  of  the  regular  substructures  which  he  will  have  to  come  up  with.  This 


.  i 


is  a  different  decomposition  of  the  problem  (rom  the  original  one,  ami  will 
impose  different  submodule  boumlaries  on  the  oveiall  device  I  he  first  stage  is 
to  examine  the  pitch  of  the  default  layouts  of  the  fragments  which  exist  in  the 
original  conception  of  the  pioblem 

We  now  enter  geometric  layout  space  where  we  ate  given  a  bunch  of 
pieces  which  are  the  external  boundaries  of  the  default  layouts  with  the 
associated  pitch  indicated  We  place  the  pieces  in  such  a  wav  as  to  try  to  limit 
the  problem  of  interconnection  A  good  first  idea  (which  is  the  default  layout 
that  the  system  stalls  us  up  with!  is  the  layout  implied  by  the  block  diagram 
We  now  abut  the  pieces  and  tiy  to  adpist  the  pitch  of  the  abutting  pieces  so  that 
they  match  We  do  this  by  communicating  the  constraint  imposed  by  the  unit 
with  the  largest  pitch  to  the  other  fragments,  which  will  perhaps  modify  their 
default  cell  layouts  I  his  constraint  is  noted  so  that  any  later  changes  to  one  of 
the  fragments  will  trigger  a  check  foi  violations  ol  the  pitch  correspondence 

A  fragment  has  a  choice  of  techniques  by  which  to  respond  to  a  request 
to  ail  just  its  pitch  I  here  may  be  a  general  expert  that  can  stretch  simple  cells, 
preserving  then  functionality  f  ailing  that,  the  fragment  may  contain  a  specific 
design  procedure  that  can  modify  the  placement  of  some  paits  in  the  layout 
prototype  in  order  to  produce  .1  new  layout  with  the  needed  pitch  Or  the 
designei  may  have  specified  internal  seams  in  t lie  s|>ecification  of  the  cell  where 
it  may  be  stretched  without  interfering  with  the  functionality,  and  where  wires 
that  pass  through  the  cell  may  be  added  Or  it  max  choose  among  a  set  of 
predefined  cell  layouts  that  the  community  of  designei s  arianged  to  be  available 
under  the  genetic  liagnicnt  type  1  in  all  v.  the  designer  can  mteiactixely  modify  a 
cell  to  produce  a  new  layout  with  the  collect  pitch  Ol  couise,  this  interaction 
may  be  postponed  at  the  designer’s  choice,  with  the  system  maintaining  a  record 
ol  dcfoiied  problems 

While  the  abutting  strategy  will  complete  main  ol  the  signal  connections, 
there  are  others  that  will  leqmre  explicit  routing  l  01  some  ol  the  cases  where 
not  much  optimization  is  possible  01  desued.  a  simple  maze  routei  is  provided 
In  other  cases,  such  as  the  interconnections  among  the  output  register,  its  preload 
control,  ami  output  buffets,  some  preplanning,  is  requited  Mire,  a  small  set  of 

bus  signals  is  sltated  among  the  fugments  in  such  a  way  that  we  suspect  that 

merging  the  three  original  blocks  into  one  will  eliminate  the  need  lor  explicit 
interconnecting  vines  We  create  .1  new  cell  type  bv  editing  together  the 

corresponding  layouts  ol  the  cells  that  wc  aie  meiging  Note  hosvcvci  that  this 
will  change  the  basic  pitch  of  the  system,  tnggcimg  the  adjustment  of  the  pitch 
of  the  coupled  fragments 

Observe  (lint  rhis  meigmg  operation  lias  appaicntlv  destroyed  the  module 
boundaries  implied  m  the  original  block  diagram  Hits  does  not  mean  that  this 
block  diagram  is  wrong  or  should  be  discarded  It  is  still  the  light  way  of 
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describing  the  functionality  of  the  device,  but  the  same  simple  hierarchical 
decomposition  no  longer  suffices  to  describe  both  the  logical  and  physical 
structure  I  he  system  must  be  able  to  manage  this  and,  for  instance,  be  able  to 
give  the  correspondence  between  signal  nodes  in  the  logical  and  physical 
representations. 

All  through  this  process  we  assume  that  the  system  is  monitoring  various 
distributed  constraints,  l  or  example,  the  actual  propagation  delay  is  compared  to 
the  design  goal  value.  The  dimensions  of  the  power  distribution  lines  depend 
upon  the  current  estimate  produced  by  the  electrical  modeling  of  the  system. 
Changes  may  result  in  a  readjustment  of  the  line  width  or  a  design  problem 
complaint  I  his  monitoring  is  motivated  by  an  assumption  that  it  is  probably 
effective  to  start  with  legal  layouts  and  preserve  the  design  correctness  by  the 
enforcement  of  constraints. 

We  have  used  such  notions  as  "the  adder  fragment"  without  ever  giving 
an  example  of  what  we  expect  such  a  piece  of  the  design  plan  language  to  look 
like.  Let  us  now  examine  the  adder  fragment  in  some  detail  to  get  a  more 
concrete  idea  of  what  we  have  in  mind.  At  the  block  diagram  level  an  adder 
abstractly  has  three  terminals,  each  of  which  is  a  word  composed  of  a  number  of 
bits.  The  number  of  bits  in  each  word  is  the  same.  The  three  terminals  are 
called  the  addend,  the  augend  and  the  sum  The  addend  and  augend  are  inputs 
and  the  sum  is  an  output.  There  is  an  extra  bit  coming  out  of  the  adder  which 
is  the  carry-out  and  there  is  an  extra  bit  coming  in  called  the  carry-in.  We 
notate  this  block-diagram  level  description  as  follows: 

(body  adder  (model  block  diagram) 

(parti  (addend  word  input) 

(augend  word  input) 

(  uim  word  output ) 

(carry-out  bit  output) 

(carry  in  bit  input ) ) 

(constraint!  ('  (length  addend) 

( length  augend) 

( length  sum) ) ) ) 

This  fragment  made  use  of  another  fragment,  word,  which  is  an  ordered 
sequence  of  bits  whose  'ength  is  the  number  of  bits. 


.declaration  of  parti 


,a  constraint 
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( body  word  (model  block  diagram) 

(parameter*  (length  number) 

(bottom  number) 

( top  number ) ) 

(sequence  (enumerator  n) 

(low  bottom) 

(high  top) 

(generic:  (part*,  ((bit  n)  bit)))) 

(constraints  (•  (•  top  bottom) 

(  length  I )))) 

Thf  adder  fragment  has  associated  with  its  block-diagram  level  several 
implementation  strategies.  The  simplest  is  the  sequence  of  full  adders  such  that 
the  carry-out  from  each  significant  hit  enters  the  carry-in  from  the  next 
significant  bit.  Another  implementation  strategy  is  the  carry  look-ahead  adder. 
We  will  only  show  the  simple  strategy  here.  Each  strategy  is  attached  to  the 
fragment  in  the  same  way. 

(  tmplcmantat  ion  »dd or  (model,  block  diagram) 

(strategy  name  simple  sequence) 

(sequence  (enumerator  n) 

(low  ») 

(high:  (-  (length  addend)  I)) 

(generic:  (parts:  ((f  n)  f ul I -adder ) ) 

(•  ((bit  (♦  n  (bottom  addend)))  addend) 

<al  (f  n))) 

(*  ((bit  (♦  n  (bottom  augend)))  euqend) 

(a?  (t  n))) 

(•  ((bit  (♦  n  (bottom  sum)))  sum) 

<»  (f  «)))) 

(between.  (■  (co  (f  *lower«))  (c'  (f  ‘upper*))))) 

( -  carry -in  (c  i  ( f  d  ) ) ) 

(-  carry-out  (co  (f  (-  (length  addend)  I))))) 

You  may  have  noticed  that  these  descriptions  of  various  aspects  of  an 
adder  have  parts  that  seem  procedural.  This  is  not  accidental.  There  is  a 
fundamental  duality  between  object  descriptions  and  procedures.  Here  we  see 
that  some  aspects  of  an  object  involve  design  procedures  which  describe  how  to 
make  a  data  structure  describing  that  aspect  of  a  particular  object. 
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Complex  Design  Procedures 

I  he  unique  aspects  of  our  approach  to  the  computer-aided  design  of 
integrated  systems  are  illustrated  by  the  use  of  design  procedures  which  are 
considerably  more  complex  than  ones  which  just  instantiate  parts  and  connect 
them  together  I  or  example,  we  can  make  design  procedures  which  assign 
propagation  delay  lonstrainis  to  the  full  adders  m  the  implementations  shown 
above  to  make  it  possible  to  get  estimates  of  the  propagation  delay  for  the  adder. 
This  can  be  used  to  decide  among  the  implementations  when  weighed  against 
other  measures  su  h  as  real  estate  taken  up  on  the  chip  and  power  consumed. 

One  powerful  kind  of  design  procedure  is  for  editing  layout  structures. 
These  procedures  allow  us  to  generalize  logic  cells  and  enhance  our  ability  to 
achieve  close  packing  and  logical  geometric  layout  of  the  cells. 

A  way  i o  generalize  a  fixed  geometry  is  for  the  designer  to  include  within 
the  cell’s  definition  a  class  of  layout  hints.  These  hints  may  be  specified  either 
when  a  cell  is  initially  defined,  or  later,  when  a  more  general  version  is  necessary. 
Some  of  these  hints  might  concern  the  options  available  for  connecting  this  cell 
with  other  cells  Tor  example,  in  the  trivial  ratioed  inverter,  the  output  node  is 
available  on  any  of  the  three  mask  levels,  metal,  polv,  or  diffusion. 

A  more  useful  hint  is  the  concept  of  a  seam.  A  scant  indicates  places  in 
the  layout  that  have  flexibility  for  expansion  and  shows  how  the  expansion  is  to 
be  done.  Scams  are  conceptual  dividing  lines  in  a  stick  cell  layout  along  which 
the  cell  may  be  expanded  and  through  which  specified  color  stick  wires  may  be 
routed.  The  scam  specifics  the  manner  in  which  cell  is  to  be  expanded  to  make 
room  for  the  newly  routed  wires.  Seam  expansion  may  require  cell  modifications 
such  as  transitions  of  interfering  signals  from  one  layer  to  another,  but  in  the 
most  common  case,  merely  involves  knowledge  of  what  parts  of  the  cell  geometry 
expand  in  which  direction.  For  example,  if  a  seam  goes  vertically  through  a 
diffusion,  the  diffusion  may  be  expanded  in  the  direction  perpendicular  to  the 
seam.  Each  seam  describes  what  materials  can  be  run  through  without  shorting 
to  a  feature  of  the  cell  or  manufacturing  a  parasitic  component. 

Suppose  that  we  had  to  run  a  signal  up  through  each  cell  of  the  adder  in 
the  multiplier-accumulator.  We  would  invoke  a  design  procedure: 

(for-each  cell  ((f  ?n)  (  accumulator-adder  null  tipi  ier -accumul  ator ) ) 

(invoke  Run-Throuqh  celt  Vertical  Poly)) 

This  iterates  the  application  of  1  he  Run-Through  procedure  over  each  part  of  the 
accumulator-adder  whose  name  matches  ((  ?n).  These  arc  the  full-adders  created 
by  implementing  it  Run-Through  examines  the  vertical  seams  of  the  full-adder 
fragment,  looking  for  one  which  can  be  used.  If  none  can  be  found  a  failure 
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message  is  produced  which  will  inform  the  caller  that  he  had  better  look  for 
another  way  to  accomplish  his  goal  or  that  he  should  tie  to  edit  the  full-adder 
cell  to  install  a  seam  which  can  do  the  job.  If  there  is  an  appropriate  seam,  the 
cell  is  stretched  and  the  poly  is  run  through.  This  changes  the  pitch  of  the  cell 
and  the  interdependent  objects  arc  informed  that  they  had  better  adjust  to  the 
new  condition.  Actually,  here,  things  are  pretty  complicated.  We  cannot  run 
polysilicon  over  a  diffusion  without  creating  an  active  transistor.  Thus,  the 
design  procedure  may  only  do  this  by  changing  the  wire  to  a  metal  one,  but  this 
takes  up  lots  of  space  so  it  can  only  be  done  if  there  is  enough  space  at  the 
desired  pitch. 

We  can  certainly  anticipate  that  a  moderately  clever  program  could 
automatically  generate  scams  within  existing  logic  cells  1  he  use  of  seams  as 
"hints"  to  the  design  system  is  one  example  of  how  we  intend  to  gradually 
develop  a  sophisticated  design  system.  In  the  initial  design  system  we  avoid  the 
requirement  that  very  complex  programs  exist,  arc  debugged,  and  are  practical  to 
use  These  design  system  hints  can  gradually  be  augmented  by  sophisticated 
programs  as  they  develop,  but  the  success  of  the  design  system  is  not  dependent 
on  their  development. 


Our  Initial  Efforts 

There  are  several  reasons  why  we  feel  it  is  important  to  adopt  an 
evolutionary  approach  to  the  development  of  the  design  system,  starting  with  the 
implementation  of  a  sophisticated  interactive  graphic  design  editor  First,  it  is 
important  to  have  some  capability  to  design  integrated  circuits  in  the  early  part 
of  the  research  project  It  is  impossible  to  create  the  advanced  design 
environment  while  working  in  a  vacuum  The  early  design  exercises  will  test  the 
significance  of  our  ideas  and  also  allow  us  to  develop  more  insight  into  the 
nature  of  integrated  system  design.  Secondly,  an  evolutionary  growth  will 
enforce  the  principle  that  each  major  module  must  have  a  clean  interface  so  that 
if  can  later  be  combined  with  more  powerful  system  components. 

Initially  we  will  construct  an  interactive  design  editor.  We  will  start  from 
the  example  of  ICARUS’’  Our  editor  will  handle  structural  models  such  as  logic 
diagrams,  mask  layouts,  and  design  descriptions  in  .1  text  form  It  will  be  capable 
of  editing  several  design  files  simultaneously  with  a  display  organized  as  multiple 
windows  Roth  color  and  high  resolution  black  and  white  screens  will  be  used. 

The  editor  commands  will  lie  interpreted  as  calls  to  primitives  of  the 
design  procedure  language  which  will  lie  operating  on  various  models  in  the 
design  plan  I  he  interactive  component  will  have  a  dean  interface  to  the  design 
procedure  system  I  he  design  plans  are  constrained  to  represent  meaningful 
structures  Thus  connectedness  infonnation  from  the  logic  schematic  is  used 


during  mask  editing  to  insure  that  the  geometric  operations  don’t  inadvertently 
destroy  the  logical  function  of  the  circuit.  Paths  of  diffusion  or  polysilicon  will 
be  stretched  and  re  layed  out  as  pieces  of  the  structure  are  moved.  The 
correspondence  between  nodes  in  the  logical  structure  and  the  geometric  layout 
will  he  maintained  automatically. 

Incremental  corrections  that  require  insertion  of  new  structures  will  be 
aided  by  automatic  editing  operations  that  move  collections  of  objects  while 
preserving  layout  design  tides. 

I  he  lay  out  model  will  consist  of  multiple  repiesenta  lions,  such  as  mask 
geometry,  SUCKS  schematics0,  and  logic  schematics  I  hesc  representations  can 
be  mixed  on  a  single  page,  where  the  more  abstract  ^presentations  stand  for 
what  will  eventually  be  mask  geometry  on  the  chip.  A  SUCKS  compiler 
transforms  the  non-metric  representation  into  mask  artwork  that  obeys  the 
process  layout  rules.  Simple  design  procedures  will  be  included  for  regular 
structures  such  as  PI  A’s  and  ROMs. 


Some  VLSI  System  Projects 

We  will  develop  several  projects  involving  the  design  of  particular  VLSI 
chips.  These  projects  cover  a  large  range  of  difficulty,  speculativcness  and  utility. 
Some  of  our  projects  are  simple  extensions  or  developments  of  existing  technology 
which  will  gi\o  us  some  familiarity  with  the  medium  and  some  perspective  with 
actual  designs  We  believe  that  it  is  useless  to  try  to  build  tools  to  aid  the 
engineering  process,  or  to  study  the  engineering  process  in  the  abstract,  without 
some  concrete  projects  to  develop  real  engineering  competence  and  taste. 

For  example,  we  have  already  developed  a  prototype  I  ISP  interpreter  chip 
which  has  been  through  design  and  fabrication  once10.  We  intend  to  use  this 
chip  and  its  successor  -  a  full  sired  interpreter  and  storage  management  system  - 
as  a  benchmark  project  to  test  some  of  our  computer  aided  design  tools  and 
methodologies  as  they  emerge. 

We  also  wish  to  design  and  fabricate  a  local-network  interface  chip.  This 
is  a  similar  "service  project"  chip  which  will  help  us  improve  our  computer 
facilities  and  which  will  provide  similar  engineering  exercises. 

I  he  Mil  VI  SI  effort  will  build  some  considerably  more  complex  systems 
using  our  computer-aided  design  technology.  These  projects  will  exercise  our 
systems  and  methodology.  Most  of  these  projects  have  direct  application  to  real 
world  problems  We  expect  to  supixnt  and  learn  from  our  interaction  with  these 
efforts 
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We  will  also  he  interested  in  some  specific  chips  for  use  in  artificial 
intelligence  research  One  area  that  seems  ripe  for  consideration  is  the  problem 
of  implementing  processes  that  operate  on  very  large  stores  of  semantically 
related  information,  such  as  the  semantic  nets  studied  In  Fahlman11.  Fahlman 
was  concerned  with  the  fact  that  most  problem  solver  programs  have  to  labor 
over  very  simple  deductions  which  seem  instantaneous  to  a  human.  For  example, 
if  we  learn  that  Cl>de  is  an  elephant,  we  can  immediately  answer  questions  such 
as  whether  Clyde  is  grey,  or  whether  he  can  climb  trees,  as  well  as  the  answers 
to  hundreds  of  other  default  facts  about  him.  Fahlman  worked  out  a  scheme  by 
which  an  important  subset  of  these  shallow  but  numerous  deductions  could  be 
done  very  efficiently  with  specially  constructed  parallel  hardware  in  the  form  of 
a  network  of  simple,  identical  processing  nodes  with  static  interconnections. 
Fahlman’s  proposal  is  communication-intensive  with  almost  no  processing  or 
memory  at  the  individual  nodes.  All  computations  in  a  fahlman  net  are  done  by 
"marker  propagation".  The  nodes  just  have  a  few  bits  of  memory  which  are 
used  to  store  markers  which  are  propagated  in  parallel  along  the  static 
interconnections 

Implementation  of  marker  propagation  networks  would  be  easy  except  for 
the  enormous  number  of  nodes  required  to  construct  a  useful  system.  We 

estimate  that  a  useful  A1  system  requires  at  least  l(r  nodes.  W'e  do  not  yet 
know  how  to  build  the  programmable  connections,  on  the  scale  required  by  such 
a  machine.  Therefore,  to  investigate  their  properties  these  systems  must  be 
simulated,  currently  on  general-purpose  computers.  Unfortunately  the  simulations 
are  far  too  slow  to  be  adequately  tested,  let  alone  be  used  as  a  support  for  other 
parts  of  a  problem  solving  system. 

\\  e  have  some  ideas  about  how  such  a  system  might  be  implemented  and 
we  expect  that  we  will  want  to  work  on  such  an  exotic  architecture  as  part  of 
our  artificial  intelligence  research  (in  cooperation  with  Fahlman,  who  is  now  at 
CMU)  One  helpful  constraint  is  that  the  computation  is  decotnposible  into 
essentially  independent  computational  nodes  such  that  each  node’s  communication 
with  other  nodes  is  limited.  When  this  is  true,  we  may  be  able  to  configure  a 
machine  so  that  the  computational  nodes  are  allocated  to  segments  of  hardware 
with  communications  lines  allocated  to  interconnect  them.  We  will  investigate  a 
spectrum  of  such  configurable  architectures. 

If  the  computational  nodes  and  the  communication  channels  to  be 
established  among  them  can  be  allocated  at  the  outset,  and  if  the  set  of  nodes 
which  must  communicate  with  a  given  node  is  small,  we  may  think  of  the 
computational  problem  as  simulating  a  "wiring  diagram".  In  fact,  one  interesting 
problem  which  breaks  up  in  exactly  this  way  is  the  simulation  and  analysis  of 
systems  which  may  be  characterized  by  lumped-parameter  models,  such  as 
electrical  circuits.17  In  a  more  general  setting,  one  can  think  of  systems  of 
algebraic  const  taints  as  networks  which  can  be  studied  as  if  they  were  electrical 
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circuits.  A  configurable  architecture  for  such  problems  is  constructed  front  a  set 
of  general-purpose  processors,  each  of  which  is  given  the  computational  task  of 
one  component  of  the  system.  The  architecture  also  requires  a  "patchboard" 
which  programs  the  intcrconncctivity  of  the  components  for  a  problem.  The 
patchboard  may  be  a  physical  entity,  such  as  a  sorting  network,  or  it  may  be 
virtual,  such  as  a  packet-switched  network.  One  useful  task  for  such  a  "circuit 
machine"  is  as  a  high-performance  digital  logic  simulator,  which  can  be  used  for 
experimenting  with  unusual  computer  architectures. 

A  class  of  architectures  that  we  will  investigate  are  network  simulators. 
We  do  not  really  understand  how  to  make  completely  parallel  network  machines, 
but  there  is  an  intermediate  position.  We  imagine  a  hybrid  between  the 
conventional  sequential  architectures  that  we  understand  and  the  fully  parallel 
architectures  that  have  not  yet  been  developed.  With  a  machine  of  this  type  we 
can  at  least  perform  experiments  on  proposed  parallel  designs  before  they  are 
constructed  A  module  in  such  a  simulator  consists  of  two  parts  --  several  large 
memories  defining  node  types,  node  states,  and  interconnections,  along  with  a 
VLSI  interpreter  engine  that  makes  a  sequential  pass  performing  a  processing  step 
on  all  nodes.  With  several  such  modules  interconnected,  networks  of  a  million 
nodes  can  be  simulated  2  or  3  orders  of  magnitude  faster  than  can  be  done  on 
purely  sequential  machines. 

The  performance  advantage  of  the  hybrid  network  simulator  comes  from 
several  sources.  First,  the  parallelism  of  the  simulator  modules  provides  a 
straightforward  factor  of  8,  16  or  so.  Second,  a  dedicated  memory  structure 
internal  lo  the  module  provides  several  times  the  bandwith  of  the  memory  on  a 
conventional  machine.  At  each  processing  tick,  the  node’s  state  and  the  state  of 
its  topological  neighbors  are  fetched  in  a  continuous  stream  of  data  pipelined  into 
the  interpreter  engine.  A  network  simulator  in  stream  mode  enjoys  much  the 
same  advantage  over  conventional  machines  as  vectorized  arithmetic  processors 
such  as  the  Cray-1  enjoy  over  scalar  processors.  T  hird,  unlike  an  instruction 
stream  driven  processor,  each  step  of  the  simulator  engine  is  interpreting  an 
independent  node  Thus  pipelining  and  overlap  can  be  freely  used  without  the 
need  of  complicated  interlock  hardware.  This  freedom  allows  cascading  several 
tnicrocodablc  processing  stages  so  that  a  multi-step  node  interpretation  can  be 
performed  in  one  cycle. 

Such  network  simulators  are  well  suited  to  experimentation  with  proposed 
designs  for  parallel  machines  having  large  arrays  of  nearly  uniform  nodes.  Some 
of  these  problem  areas  are  digital  logic  simulation,  marker  propogation  in 
semantic  nets,  and  pattern  matching  for  Al  data  base  systems.  However,  in 
addition  to  being  a  research  vehicle  for  parallel  architectures,  the  hybrid 
sequential/parallcl  computer  is  a  novel  architectural  paradigm  that  may  have 
applications  in  many  domains  where  the  natural  formulation  of  computation  is 
object  based  .is  opposed  to  function  based.  We  may  find  such  possibilities  in 
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areas  such  as  signal  processing  ami  discrete  panicle  simulations 


Notes 

1.  This  cognitive  complexity  barrier  has  been  apparent  for  some  time  in  the 
design  of  large  software  systems.  The  development  of  very  high  level  languages 
ts  one  approach  to  controlling  this  complexity.  Soli  ware  engineers  have  also 
developed  methodologies  such  as  "stiuctured  programming"  [Dahl,  Dijkstra  & 
Hoare  1  *">7 2 1  to  help  cope  with  the  problem  Our  engineering  Problem  Solving 
project  is  an  outgrowth  of  another  approach  concerned  with  the  construction  of 
intelligent  design  tools  (Wmograd  1973)  We  .ire  engaged  in  related  research  on 
the  computer-aided  design  and  analysis  of  analog  electrical  circuits  [Sussman 
1 07 7 ;i )  and  of  software  systems  |Rich,  Shrobe,  Waters,  Snssman,  &  Hewitt  1978). 

2.  Snssman  [Snssman  1973)  [Snssman  1977a)  introduced  a  theory  of  problem 
solving,  called  Problem  Solving  by  Debugging  Almosf-Right  Plans,  which  is  based 
on  deliberately  making  simplifying  assumptions  which  may  introduce  "bugs"  into 
the  solution.  I  he  resulting  solution  is  then  debugged  until  it  is  right.  This 
theory  was  induced  from  observations  of  engineers  and  programmers  in  the 
process  of  design. 

3  The  distinctions  between  a  "performance  theory"  and  a  "competence  theory" 
for  describing  aspects  of  the  behavior  of  humans  was  introduced  by  Chomsky 
[Chomsky  1965)  m  the  context  of  natural  linguistics  1  ooscly  speaking,  a 
competence  theory  concentrates  on  the  factual  issues  ot  a  domain  whereas  a 
performance  theory  is  concerned  with  the  issues  ol  control  and  heuristics. 

4  Iho  power  of  a  structuieil  theory  ol  design  is  demonstrated  by  Mead  and 
C'onwav  in  their  beautiful  book  [Mead  .k  Convv.tx  1979]  on  the  design  of  VI  SI 
systems.  I  hex  have  isolated  a  level  of  language  which  is  natural  lor  the  design 
of  interesting  classes  of  NMOS  chips.  1  hey  speak  in  ter  ms  ot  "state  machines", 
"programmed  logic  arrays",  "bussed  register  arrays",  "multiplexers”  and  other 
concepts  which  are  primitives  of  a  much  higher  level  language  than  the  AND, 
OR,  NO  I,  JK  flip-flop  level  of  detail  which  most  digital  designers  are  used  to. 
Using  their  ideas,  students  are  able  to  design  veiy  complex  \  1  SI  systems  with 
only  a  small  amount  of  practice.  Structured  programming  [Dahl,  Dijkstra,  ik 
Hoare  197,7)  has  had  a  similar  but  more  controversial  effect  on  the  work  of 
programmers 

1  he  use  of  a  special  formalism  for  describing  an  electrical  circuit  from  several 
points  of  view  simultaneously,  so  that  an  automatic  deductive  system  could  make 
use  of  information  deduced  from  each  model  was  introduced  bv  Snssman 
[Snssman  l <>771x1  Steele  and  Snssman  [Steele  .k  Snssman  1979;.)  have  generalized 
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the  notion  to  he  useful  for  the  description  of  olher  ";ilmost  hierarchical  systems" 
which  result  from  engineering  design 

6.  "Propagation  of  constraints”  was  originally  invented  as  a  generalization  of 
"Guillemiu’s  method"  of  analyzing  electrical  ladder  circuits.  It  was  used  in  the 
analysis  programs  FI  [Sussman  Si  Stallman  1075]  and  ARS  (Stallman  &  Susstnan 
1976],  and  in  the  synthesis  program  SYN  (de  Kleer  Si  Sussman  1978].  The  basic 
idea  of  the  method  was  first  described  in  [Drown  1975]  as  part  of  a  method  for 
localizing  faults  in  electrical  circuits.  De  Kleer  also  used  propagation  analysis  in 
his  fault  localizer  (de  Kleer  1976]  Sutherland  (Sutherland  1963]  appears  to  have 
developed  a  similar  technique  (the  "One  Pass  Method")  for  constraint  satisfaction 
in  Sketchpad 

7.  SIMULA  (Dahl  Si  Nygaard  1%6]  introduced  the  "class"  as  an  abstraction 
mechanism  in  a  programming  language. 

8.  ICARUS  is  a  minimal  automated  geometric  draftsman  developed  at  Xerox 
PARC  by  Fairbairn  and  Rowson  [Fairbairn  Si  Rowson  78]. 

9.  STICKS  is  a  semi-geometrical  graphical  representation  of  the  layout  of  an 
integrated  design.  Features  on  various  mask  layers  are  represented  by  lines  of 
appropriate  color  STICKS  diagrams  show  all  topological  information  and 
approximate  layout,  but  they  suppress  most  metric  information. 

10.  Our  chip  (Steele  &  Sussman  1979b]  is  an  interpreter  and  storage  manager  for 
a  dialect  of  LISP  called  SCHEME.  It  was  part  of  the  MIT  project  set  for  the 
Fall  of  1978.  Lynn  Conway  of  PARC  was  teaching  at  MIT. 

11.  Fahlman’s  semantic  memory  scheme  is  described  in  (Fahlman  1977], 

12  John  Kassakian  [Kassakian  1979]  has  a  neat  new  approach  to  the  simulation 
of  complex  electronic  systems  which  he  calls  the  "Parity  Simulator".  The  basic 
idea  is  that  he  automatically  configures  a  set  of  universal  elements  so  that  each 
simulates  a  device  in  a  network  and  he  configures  the  interconnection  between 
them  to  be  isomorphic  to  the  interconnections  in  the  netowrk  being  simulated. 
This  turns  out  to  be  better  for  many  applications  than  the  traditional  approach 
of  simulating  the  behavior  of  the  equations  resulting  from  an  analysis  of  the 
network. 
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